Domain Name System Security Extensions (DNSSEC) is a set of security extensions to DNS that provides a way for authenticating DNS records. DNSSEC is defined by the IETF in RFCs 4033, 4034, and 4035. Each answer from a DNS SEC protected zone is digitally signed. DNSSEC provides a way for DNS records to be trusted by whoever receives them. DNSSEC uses public key cryptography to ensure that DNS records are authentic. DNSSEC not only allows a DNS server to prove the authenticity of the records it returns, it also allows the assertion of “non-existence of records”. The DNSSEC trust chain is a sequence of records that identify either a public key or a signature of a set of resource records. The root of this chain of trust is the root key which is maintained and managed by the operators of the DNS root.
Several record types are defined by DNSSEC including DNSKEY, DS, and RRSIG. The DNSKEY record type is a public key used to sign a set of resource records (RRset). The Delegation Signer (DS) record type is a delegation signer (a hash of a key). The RRSIG record type is a signature of a RRset that shares name/type/class. The DNSKEY can be classified into two roles, which can be handled by separate keys or a single key. For example, a key signing key (KSK) can be used to sign DNSKEY records. A zone signing key (ZSK) can be used to sign all other records in the domain in which it is authoritative for.
The set of all records of a given type for a domain name is called an RRset. An RRSIG (Resource Record SIGnature) is essentially a digital signature for an RRset. Each RRSIG is associated with a DNSKEY. The RRset of DNSKEYs are signed with the key signing key (KSK). All others are signed with the zone signing key (ZSK). Trust is conferred from the DNSKEY to the record though the RRSIG: if you trust a DNSKEY, then you can trust the records that are correctly signed by that key.
However, the domain's KSK is signed by itself, making it difficult to trust. The way around this is to walk the domain up to the next/parent zone. To verify that the DNSKEY for example.com is valid, you have to ask the .com authoritative server. This is where the DS record comes into play: it acts as a bridge of trust to the parent level of the DNS.
The DS record is a hash of a DNSKEY. The .com zone stores this record for each zone that has supplied DNSSEC keying information. The DS record is part of an RRset in the zone for .com and therefore has an associated RRSIG. This time, the RRset is signed by the .com ZSK. The .com DNSKEY RRset is signed by the .com KSK.
The ultimate root of trust is the KSK DNSKEY for the DNS root. This key is universally known and published. By following the chain of DNS KEY, DS and RRSIG records to the root, any record can be trusted.
These records are enough to prove the integrity of a resource record, but something more is needed in order to prove that a record does not exist. This is where two additional record types, NSEC and NSEC3, come into play.
If a DNS authoritative server knows there is no record for a specific request, it has a way to respond to such requests. When the name asked for does not exist, it returns a message that has return code (RCODE) NXDOMAIN. When the name exists, but the requested type does not, it returns a NODATA response, i.e., empty answer.
These non-existence answers are unauthenticated and could be forged by a third party just like any other DNS response. However, DNSSEC solves this problem by creating a record type that expresses what names exist, and what types reside at each name. This record is called NSEC. An NSEC can be signed by DNSSEC, and validated up to the root. Typically, NSEC is used to cover gaps between all the domains with records in the zone. In most cases, this effectively doubles the number of records in the zone, but allows an authoritative nameserver to reply with a signed response for any question.
The zone ietf.org. uses NSEC records. Asking for ‘trustee.ietf.org’ would give you a positive answer with an IP address and an RRSIG record. Asking for ‘tustee.ietf.org’ would give you a negative answer ‘there are no name between trustee.ietf.org and www.ietf.org’, with a corresponding RRSIG.
NSEC records require complex and unusual database access to get a list of existing types for a name, which is a source of instability. Also, NSEC makes a proxy DNS DNSSEC system unfeasible since there is no knowledge of the record types exist on the origin.
This frustrates the generation of an NSEC with incomplete knowledge of the zone. NSEC is essentially a statement that says “these types do not exist”. By way of example, if the infrastructure provider does not know that a mail exchanger (MX) record exists at the Canonical Name (CNAME) target and an NSEC is sent that says “MX does not exist”, then (a) a smart resolver might decide later not to make a query for MX since it knows from the NSEC that it “does not exist”; and (b) an attacker can replay that NSEC to answer a query for MX and make the client believe it does not exist when in fact it does.